New name for DeferredFutureSingle and DeferredFutureMaybe #1
Conversation
Bon, ils sont là, "relativement" visibles:
|
|
Je m'interroge quand même sur le fait que Que penses-tu de |
|
Moi non plus je ne suis pas ultra fan de Ce serait idéal, Par contre... on pourrait renommer les protocoles en |
|
OK on fait ça ! |
|
Non on ne fait pas ça ! Si le protocole est |
@pakko972, j'ai renommé les deux publishers qu'on peut créer avec une closure, et enlevé le namespace
TraitPublishersqui ne sert plus à rien, du coup:Tu penses que ça peut aider à s'en rappeler ?
On avait aussi
SingleDeferredFutureetMaybeDeferredFuture, qui ont l'avantage de commencer par le mot désiré et sont donc sympas avec l'autocompletion. Mais j'ai trouvé queMaybeDeferredFutureavait trop d'interprétations erronées (genre: "Hu? It may be deferred? What does it mean?").Autres options qui ne m'ont pas convaincu:
AnySinglePublisher.create { ... }, trop inspiré de RxSwift, pas assez parlant pour les "Combine-natives".AnySinglePublisher.make { ... }, flouAnySinglePublisher.deferred { ... }, on s'attend à ce que la closure renvoie un publisher, à cause de Combine.Deferred.AnySinglePublisher.future { ... }, on s'attend à ce que la closure soit lancée immédiatement, avant la subscription, à cause de Combine.Future (un éjaculateur précoce, ce Combine.Future, ce qui pose plein de problèmes).AnySinglePublisher.deferredFuture { ... }, plus tellement mieux queDeferredFutureSingle { ... }